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(57) Abstract: The invention 
relates to a method for enabling 
a new version of an application 
to be loaded onto a computer 
processing device. According 
to said method, information 
on the correspondence (II, 13, 
14, 16) between the classes (A 
to D) of the old version of the 
application and the classes (A 
to F) of the new version of the 
application, and information 
about correspondence between 
the static fields of the old version 
of the application and static 
fields of the new version of the 
application, is calculated prior to 
the loading. Said correspondence 
information is then associated 
in order to modify the objects in 
such a way that they point towards 
classes of the new version and use 
the new identifiers of the static 
fields of the new version of the 
application. 



(57) Abrege : Le precede selon l'invention permet le chargement sur un dispositif informatique d'une nouvelle version d'une appli- 
cation. II consiste a calculer, prealablement a ce chargement d'une part une information de correspondance (II, 13, 14, 16) entre les 
classes (A a D) et (A a F) de l'ancienne version de l'application et de la nouvelle version de l'application et d'autre part, une informa- 
tion de correspondance entre les champs statiques de l'ancienne version et de la nouvelle version de l'application, puis a associer ces 
informations de correspondance pour modifier les objets de facon a ce qu'ils pointent vers les classes de la nouvelle version et qu'ils 
utilisent les nouveaux identificateurs des champs statiques de la nouvelle version de l'application. 
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5 PROCEDE DE MISE A JOUR D T APPLICATIONS POUR CARTE A PUCE. 



10 La presente invention concerne im procede de mise a jour ^applications pour 
carte a puce. 

Elle a plus particulierement pour objet de permettre le chargement d'une 
nouvelle version d'une application dans une carte a puce tout en conservant les 
15 donnees utilisees par les precedentes versions de Implication. 

La plupart des systemes de cartes a puce actuelles utilisent des machines 
virtuelles, la plus populaire d'entre elle etant celle de « Java Card » (marque 
deposee par la Societe Sun Microsystems). Dans ce systeme, les donnees 

20 persistantes des applications sont stockees comme des objets, et en particulier 
comme des instances des classes definies dans les programmes charges dans la 
carte. La nature persistante de ces objets rend done les programmes actifs en 
permanence dans la carte, a l'inverse de ce qui se produit dans les systemes 
classiques (stations de travail, ordinateurs de bureau). Cela pose un probleme 

25 particulier pour la mise a jour des programmes, puisqu'il n'est pas possible de 
profiter d'un moment ou le programme n'est pas actif pour le mettre a jour. 

De plus, la plupart des plates-formes utilisent un format de code binaire 
optimise (format dit « CAP File » dans le cas de « Java Card »). Ce format 
30 permet de ne charger sur une carte que les informations strictement 
necessaires a Texecution du programme. En particulier, il ne contient pas 
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toujours les informations necessaires pour effectuer une mise a jour de 
Tapplication. 

Enfin, une carte a puce est un contexte d'execution tres particulier, dans la 
5 mesure ou elle est difftisee en de tres nombreux exemplaires, et elle contient 
souvent des informations confidentielles. En particulier, il est tres difficile 
d'envisager de mettre a jour une application en effa?ant Tapplication existante 
et ses donnees, en rechargeant la nouvelle application, puis en rechargeant les 
donnees. En effet, les donnees ^initialisation des applications sont 
10 generalement tres sensibles, et ne doivent absolument pas etre manipulees en 
dehors des sites de production des cartes, sous des conditions de securite tres 
controlees. 

La nature des problemes rencontres depend fortement des caracteristiques de 
15 la mise a jour souhaitee. Pour la mise a jour d'une application, les problemes 
sont les suivants : 

• Mise a jour de code simple. 

Le probleme est ici de corriger des defauts du programme, sans en modifier 
20 la structure. II s'agit done simplement de modifier la definition de certaines 
methodes, et eventuellement de raj outer de nouvelles methodes, voire de 
nouvelles classes (en dehors de la hierarchie existante). 

• Mise a jour de code avec modification de la hierarchie de classes. 

25 Le probleme est ici de corriger des defauts structured du programme, 
necessitant une modification de la hierarchie de classes (habituellement par 
insertion d f une classe au milieu d'une hierarchie existante pour prendre en 
compte un comportement specifique). 



WO 2005/064459 PCT/FR2004/003353 

3 

• Mise a jour avec modification de la structure de l'objet. 

Le probleme est ici de corriger un defaut necessitate le stockage 
d f informations supplementaires, et done Taj out de champs de donnees dans 
des classes existantes. Ce probleme est plus complexe dans la mesure ou les 
5 objets existants doivent etre modifies pour prendre en compte les 
modifications. 

Dans certains cas, l'application a mettre a jour est accessible depuis d'autres 
applications, en particulier quand l'application exporte des interfaces 
10 partageables et quand l'application est en fait une librairie. D'un point de vue 
purement technique, de telles mises a jour posent les memes problemes que les 
mises a jour simples d' applications, a la difference pres que les mises a jour 
doivent etre appliquees a toutes les applications qui importent les fonctions 
modifiees. 

15 

L r invention a done plus particulierement pour but la realisation d'un 
mecanisme de chargement d f une nouvelle version d'une application, qui 
remplace une application deja presente sur une carte avec des garanties en 
matiere de securite et de continuity de fonctionnement, ce mecanisme 
20 permettant done de modifier des applications sans interrompre leur 
fonctionnement. 

Elle se propose d'aboutir a ce resultat en utilisant une option specifique de 
commande de chargement et un format de chargement compatible avec celui 
25 defini dans la specification « Java Card ». 

En vue de parvenir a ces resultats, elle propose, d f une fa9on generate, un 
procede pour le chargement sur un dispositif informatique d'une nouvelle 
version d'une application dans un langage de programmation a objets et 
30 permettant, notamment, Tintroduction de classes supplementaires, la 
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modification de la hierarchie de classes et la definition de champs et de 
methodes supplementaires. 

Selon invention, ce procede consiste a : 

5 

- calculer prealablement a ce chargement une information permettant d'etablir 
la correspondance entre les classes de Tancienne version de Implication et 
les classes de la nouvelle version de Tapplication ; 

- calculer prealablement a ce chargement une information permettant d'etablir 
10 la correspondance entre les identificateurs des champs statiques de 

Tancienne version de Tapplication des identificateurs des champs statiques 
de la nouvelle version de Implication ; 

- associer lesdites informations de correspondance a la nouvelle version de 
Tapplication chargee sur le dispositif ; 

15 - utiliser lesdites informations de correspondance pour modifier les objets de 
fa9on a ce qu'ils pointent vers les classes de la nouvelle version de 
Tapplication et qu ? ils utilisent les nouveaux identificateurs des champs 
statiques de la nouvelle version de Tapplication. 

20 Avantageusement, lesdites informations de correspondance pourront consister 
en des tables de correspondance. 

Elles pourront etre omises dans le cas ou les modifications des objets ne sont 
pas necessaires, par exemple, et de fa9on non limitative, quand aucune classe 
25 supplementaire n f est ajoutee dans la nouvelle version de l'application ou quand 
les classes ajoutees ne modifient pas la hierarchie de classes. 



Le procede selon Tinvention pourra comprendre Texecution de methodes de 
mise a jour des donnees de Tapplication apres installation de la nouvelle 
30 version de Tapplication. 
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Un mode d'execution de rinvention sera decrit ci-apres, a titre d'exemple non 
limitatif, avec reference aux dessins annexes dans lesquels : 

Les figures la et lb sont des tableaux comparatifs montrant la 
5 hierarchie de classes de Implication, dans sa version originale (figure 

la) et dans sa nouvelle version (figure lb) ; 

La figure 2 est une table de correspondance dormant, pour chaque 
classe de Tapplication originale, Tindex de la classe correspondante 
10 dans la nouvelle application ; 

Les figures 3a et 3b sont des tableaux comparatifs montrant une 
hierarchie avec la propriete recherchee, hierarchie originale (figure 3 a) 
et nouvelle hierarchie (figure 3b) ; 

15 

La figure 4 est une table de correspondance entre des tables de 
correspondance (table originale/nouvelle table) correspondant a la 
hierarchie illustree figure 3b ; 

20 La figure 5 est une table de correspondance du type de celle de la figure 

4 pour les champs statiques ; 

Les figures 6 a 8 sont des representations schematiques illustrant les 
etats d'une carte a puce, avant mise a jour (figure 6), apres chargement 
25 de la nouvelle application (figure 7) et apres modification des objets 

(figure 8). 

La mise en oeuvre de Tinvention se fait en plusieurs etapes : 



30 



Preparation du fichier de chargement. 
Chargement du fichier et edition de liens. 
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• Mise a jour des objets de Implication. 

• Execution d'une methode specifique de mise a jour. 

Le fichier de chargement doit contenir des informations specifiques qui 
5 permettent d'etablir la correspondance avec une ou plusieurs versions 
anterieures de Implication. Afin de generer le fichier de mise a jour, il est 
necessaire de disposer des objets suivants : 

• Tous les fichiers de classe de Tapplication originale. 

10 • Le fichier de chargement (« CAP File » dans le cas de « Java Card ») de 
l'application originale. 

• Tous les fichiers de classe de la nouvelle version de Implication. 

• Tous les fichiers d'export requis pour construire la nouvelle version de 
Tapplication. 

15 

Si le fichier de chargement de Tapplication originale comprend des 
informations de typage et de nommage des classes, il n ! est alors pas 
indispensable de disposer des fichiers de classe de Tapplication originale. 

20 Les donnees d'entrees doivent respecter les contraintes suivantes : 



• Pour chaque element de Tapplication originale, il existe dans la nouvelle 
version de ^application un element equivalent (de meme nom et de meme 
type). 

25 • Si Tapplication originale exporte une interface exteme aux autres 
applications, cette interface externe doit etre inchangee dans la nouvelle 
version de l'application. 

• Les fichiers d'export utilises dans la nouvelle version de Tapplications sont 
binaires-compatibles (c f est-a-dire qu'ils peuvent etre relies sans 

30 modification aux autres parties de Tapplication initiale) avec ceux utilises 
dans Tapplication originale. Dans le cas de « Java Card », il s f agit de ceux 
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qui sont listes dans le composant d'import du fichier de chargement 
original. 

Le fichier de chargement genere est un fichier de chargement normal, qui peut 
5 done etre charge sur n'importe quelle carte. Ce fichier contient un composant 
optionnel avec les informations suivantes pour chaque version precedente de 
Implication prise en consideration : 

- le numero de cette version, 

10 - une table qui etablit une correspondance entre chaque classe ou interface 
definie dans Tancienne version et la nouvelle version de cette classe ou 
interface dans la nouvelle version de Tapplication, 

- une table qui etablit une correspondance entre Tidentifiant de chaque champ 
statique de l'ancienne version et le nouvel identifiant de ce champ dans la 

1 5 nouvelle version. 

Ces informations supplementaires ne sont necessaires que pour les operations 
de mise a jour. Le meme fichier binaire peut done servir pour le chargement 
de l'application et pour la mise a jour ^applications. 

20 

Dans un premier exemple, les hierarchies de classe de l'application dans sa 
version originale et dans sa nouvelle version sont montrees sur les figures la 
et lb. La hierarchie originale comporte quatre classes (Classe A a Classe D) et 
la nouvelle hierarchie comporte quatre classes supplementaires (Classe E, 
25 Classe F, Classe A2, Classe C2) dont certaines (Classe A2 et Classe C2) sont 
inserees dans la hierarchie originale. 

Dans ce cas, une table de correspondance peut etre etablie. 
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Comme illustre figure 2, cette table de correspondance peut, par exemple, 
donner, pour chaque classe de Implication originale, l'index II, 13, 14, 16 de la 
classe correspondante dans la nouvelle application. 

5 L'exemple suivant concerne un cas particulier dans lequel la table 
supplementaire n ! a pas besoin d'etre incluse dans le fichier de chargement. 
Ceci est possible si : 

• La hierarchie des classes de Implication originale est conservee inchangee 
10 dans la nouvelle version de Tapplication (aucune classe n f est inseree dans la 

hierarchie). 

• Les classes de Tapplication originale sont definies en premier dans le 
nouveau ficher de chargement, et dans le meme ordre que dans le fichier de 

1 5 chargement original . 

Les figures 3 a et 3b montrent une hierarchie avec la propriete recherchee dans 
laquelle la nouvelle hierarchie (figure 3b) inclut les classes E et F sans 
insertion dans la hierarchie originale (figure 3a) des classes A a D. 

20 

La figure 4 montre les tables de classes correspondant a cette hierarchie, et 
respectant la propriete d f ordre indiquee ci-dessus. On voit alors que la table de 
correspondance est triviale et n'est pas necessaire. 

25 Le fichier doit egalement contenir une table de correspondance entre les 
champs statiques de Fapplication originale et ceux de la nouvelle version de 
Tapplication. Cette table est similaire a la precedente, mais elle est cette fois 
indexee par les identifiants des nouveaux champs statiques ; les elements de la 
table qui correspondent a des nouveaux champs contiennent un identifiant 

30 invalide (10 dans Texemple), et les autres elements contiennent Tidentifiant du 
meme champ dans la version originale. 
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La figure 5 montre un exemple d'une telle table comprenant : 

- une table originate comportant les champs A.champl, A.champ2, 
5 C.champl, A.champ3, 

- une nouvelle table comportant les champs A.champ2, A.champl, 
C.champl, C.champ2, A.champ3, F.champl, 

10 - une table de correspondance dans laquelle le champ A.champl est indexe 
par Tidentifiant II, A.champ2 est indexe par Tidentifiant 12, C.champl est 
indexe par Tidentifiant 13 , A.champ3 est indexe par Tidentifiant 14 ; les 
nouveaux champs C.champ2 et F.champl contiennent un identifiant 
invalide = 10. 

15 

Une fois le fichier approprie genere, il faut le charger dans la carte. On peut 
supposer que Tetat de la carte avant chargement est comme indique en figure 6 
avec un objet Objl en ClasseA et un objet Obj2 en ClasseB de Tapplication 
Appl. 

20 

Le chargement s'effectue en utilisant la procedure d'edition de liens normale 
du systeme. 

La figure 7 montre Tetat de la carte apres le chargement de la nouvelle 
25 application. La nouvelle version de Tapplication Appl 1 est chargee, mais les 
objets Objl, Obj2 de Tapplication pointent toujours vers Tancienne version 
(ClasseA, ClasseB de Tapplication Appl). 

Une des phases du chargement est Tinitialisation des champs statiques. La 
30 procedure standard d f initialisation est appliquee, sauf pour les champs qui sont 
herites de Tapplication originate. Pour ces champs, la valeur initiate definie 



WO 2005/064459 PCT/FR2004/003353 

10 

dans la nouvelle version de Implication est ignoree, et Tancienne valeur est 
copiee. 

L'etape suivante consiste done a modifier les liens des objets pour qu'ils 
5 pointent vers les nouvelles classes. II faut alors parcourir tous les objets de 
Tapplication et utiliser la table de correspondance entre anciennes et nouvelles 
classes pour identifier la nouvelle classe de Tobjet 

Le resultat est montre figure 8, ou les objets Objl, Obj2 pointent sur les 
10 nouvelles classes (ClasseA', ClasseB 1 ). 



Lors de cette etape, il se peut que les objets doivent etre modifies, si de 
nouveaux champs ont ete ajoutes a leur classe. Dans ce cas, un nouvel objet 
(avec les nouveaux champs) est alloue, les valeurs des anciens champs sont 
15 copiees de Tancienne version de l'objet, et les valeurs des nouveaux champs 
sont initialisees a leur valeur par defaut (0 pour les entiers ? "false 1 ' pour les 
booleens, et "null" pour les pointeurs). Les references vers l'ancien objet sont 
ensuite mises a jour en utilisant des techniques classiquement implementees 
dans les recuperateurs de memoire. 

20 

La derniere etape consiste a laisser Tapplication faire toutes les operations 
necessaires a la mise a jour des donnees et ? en particulier, de proceder a 
Tinitialisation des nouveaux champs (champs statiques, ou champs inseres 
dans des objets). Les applets qui ont besoin d'effectuer une mise a jour doivent 
25 implementer une interface specifique, dans laquelle une methode est definie. 
La mise a jour consiste done a parcourir la table des applets enregistrees dans 
le systeme et, pour chaque applet qui est une instance d f une classe definie dans 
le package mis a jour et qu'implemente Tinterface de mise a jour 5 d'invoquer la 
methode avec les parametres appropries. 
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1. Procede pour le chargement sur un dispositif informatique d f une 
nouvelle version d'une application dans un langage de programmation a objets 
5 et permettant, notamment, l'introduction de classes supplementaires, la 
modification de la hierarchie de classes et la definition de champs et de 
methodes supplementaires, 
caracterise en ce qu'il consiste a : 



10 - calculer prealablement a ce chargement une information permettant d'etablir 
la correspondance entre les classes de Tancienne version de Implication et 
les classes de la nouvelle version de Tapplication ; 

- calculer prealablement a ce chargement une information permettant d'etablir 
la correspondance entre les identificateurs des champs statiques de 

15 Fancienne version de Tapplication des identificateurs des champs statiques 
de la nouvelle version de Implication ; 

- associer lesdites informations de correspondance a la nouvelle version de 
Tapplication chargee sur le dispositif ; 

- utiliser lesdites informations de correspondance pour modifier les objets de 
20 fa9on a ce qu'ils pointent vers les classes de la nouvelle version de 

Tapplication et qu f ils utilisent les nouveaux identificateurs des champs 
statiques de la nouvelle version de Tapplication. 



2. Procede selon la revendication 1, 

25 caracterise en ce que lesdites informations de correspondance sont des tables 
de correspondance. 

3. Procede selon Tune des revendications 1 et 2 9 

caracterise en ce que lesdites informations de correspondance sont omises 
30 dans le cas ou les modifications des objets ne sont pas necessaires quand 
aucune classe supplementaire n'est ajoutee dans la nouvelle version de 
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l'application ou quand les classes ajoutees ne modifient pas la hierarchie de 
classes. 



4. Procede selon Tune des revendications precedentes, 
5 caracterise en ce qu f il comprend Texecution de methodes de mise a jour des 
donnees de l'application apres rinstallation de la nouvelle version de 
Tapplication. 



5. Procede selon Tune des revendications precedentes, 
10 caracterise en ce que ledit dispositif inforaiatique est une carte a puce. 



6. Procede selon Tune des revendications precedentes, 
caracterise en ce que ledit langage de programmation est le langage « Java 
Card ». 
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